While the flow of messages through a delivery system seems simple: a message flows in, the message flows out, in practice, message delivery is often more difficult than it may at first glance appear. One type of message delivery is e-mail, electronic mail exchanged via communication between computers over a network. There are a number of commercially available e-mail systems including Microsoft's Exchange, IBM's Lotus Notes, Sendmail, Postfix and others.
The delivery of e-mail generally requires the use of a Mail User Agent (MUA), a client program that enables a user to send and receive e-mail, a Mail Transfer Agent (MTA), a server program that enables e-mail transfers from one machine to another and a Mail Delivery Agent (MDA), a program used by the MTA to put mail content into a user's mailbox or to transport e-mail to another MTA, and possibly a Mail Retrieval Agent (MRA), a program or service that fetches mail content from a mailbox on a remote server and passes it to an MUA. In some Message Transfer Systems an MTA does not actually deliver e-mail: it prepares a message (e.g. by insuring that the envelope is acceptable to the receiving server) and calls an MDA to physically transport the message. SMTP (Simple Mail Transfer Protocol) is a protocol commonly used for sending and receiving e-mail.
SMTP has the capability to transport e-mail across networks. A network may consist of mutually-TCP-accessible hosts on the public Internet, mutually-TCP-accessible hosts on a firewall-isolated TCP/IP Intranet, or hosts in some other LAN or WAN environment utilizing a non-TCP transport-level protocol. Using SMTP, a process can transfer e-mail to another process on the same network or to some other network via a relay or gateway process accessible to both networks. Thus, an e-mail message may pass through a number of intermediate relay or gateway hosts on its path from sender to ultimate recipient. SMTP is independent of the particular transmission subsystem, requiring only a reliable ordered data stream channel.
In common usage, the two hosts participating in an SMTP transaction are described as the “SMTP-sender” or the “SMTP client” and “SMTP-receiver” or “SMTP server”. A given host may act both as server and client in a relay situation. The responsibility of an SMTP client is to transfer an e-mail message to one or more SMTP servers, or report its failure to do so. To transfer an e-mail message to an SMTP server, an SMTP client determines the address of an appropriate host running an SMTP server by resolving a destination domain name, and establishes a two-way transmission channel to that SMTP server. The SMTP client normally initiates an e-mail transaction consisting of a series of commands. The commands specify the originator and destination of the e-mail and the mail content (including any headers or other structure). SMTP replies are sent from the SMTP server to the SMTP client in response to the commands. The SMTP server that receives the transaction may be either the ultimate destination or an intermediate relay (that is, e-mail message transfer can occur in a single connection between the original SMTP-sender and the final SMTP-recipient, or can occur in a series of hops through intermediary systems).
SMTP servers and clients act as MTAs. MUAs are normally thought of as the sources and targets of mail. At the source, an MUA might collect mail to be transmitted from a user and hand it off to an MTA; the final (delivery) MTA would be thought of as handing the mail off to an MUA (or at least transferring responsibility to it, e.g., by depositing the message in a “message store” via an MDA).
SMTP transports an e-mail message. A message includes an envelope and content. The SMTP envelope is sent as a series of SMTP protocol units including an originator address (to which error reports should be directed); one or more recipient addresses; and optional protocol extension material. An address is a character string identifying a user from whom mail is sent or to whom mail will be sent or a location into which mail will be deposited. A mailbox refers to the mail depository. The two terms mailbox and address are typically used interchangeably unless the distinction between the location in which mail is placed (the mailbox) and a reference to it (the address) is important. The SMTP mail content is sent in the SMTP DATA protocol unit: that is, the material transmitted after a DATA command is accepted and before the “end of data” indication is transmitted is referred to as message content or mail data. Message content includes message headers and a possibly-structured message body. Headers typically include subject (typically used for a summary of the contents of the message), the e-mail address of the sender, the e-mail address of the receiver, and local time and date when the message was sent. The body is the text message itself (the letter, to analogize with traditional mail), and may include a signature block at the end.
When the recipient of an e-mail message resolves to a plurality of recipients, as in the case of an e-mail addressed to a distribution list (mailing list, group, or alias), the address is expanded, that is, a copy of the message is forwarded or redistributed to each mailbox in the expanded list. Thus, receipt of a single e-mail message sent to “ALL EMPLOYEES” of a very large company may result in the explosion of that e-mail into tens, hundreds, thousands or even more messages to be delivered, potentially causing the messaging system to be overwhelmed by the number of messages to be sent. Alternatively, receipt of the message may result in a single e-mail addressed to a very large number of recipients. While sending a single message is efficient, if the single message is addressed to a very large number of recipients, system resources (such as memory, for example) may be overtaxed, potentially causing system slowdown or even failure. It would be helpful if there were a way to expand messages in a reasonably efficient, predictable way that does not overtax system resources.
There exists in the marketplace a demand for extensibility of e-mail systems. Users may, for example, want to have their e-mail evaluated by anti-spam software, anti-virus software or to be handled according to a set of policy rules and so on. It would be helpful if there were a way to provide users with extensibility so that a generic message transfer system could be customized to meet a company's particular needs without re-writing the message transfer software. It would also be helpful if there were a way to enable a single e-mail addressed to a number of recipients to be treated differently for some recipients as specified, for example, by a set of policy rules reflected in the coding of external modules that could “plug in” to the generic message transfer system. It would be helpful to provide these enhancements while protecting the users from potential deleterious effects that arise because of existing features in message delivery systems such as distribution list processing.
Sometimes a problem is detected as a message is being processed by an MTA. For example, the set of assumptions valid when the message was received by the MTA may have changed, system configuration may have changed, or some error condition may have occurred. Known systems attempt to keep track of the progress of the message, try to correct the problem as well as possible and resume processing from that point. This approach often leads to unpredictable and incorrect results. It would be helpful if there were a more predictable solution that is likely to result in successful delivery more often.